The distributing of audiovisual programs to terminals is generally carried out in the form of data streams using the IP protocol.
These streams are multicast using a particular destination address, making it possible to dispatch an audiovisual program simultaneously to several recipients. Accordingly, these recipients must have subscribed to a group, called a multicasting group, designated by the particular destination address. One speaks of “multicast” broadcasting.
When a terminal subscribing to a multicast group is connected to a network by way of a router (also called an access point), this router is added to a multicasting tree for this group. In this way, the terminal can receive, by way of this router, the programs to which it has subscribed.
When the terminal changes network, it is necessary for the new network access router to be added to the multicasting tree for the multicasting group to which the terminal has subscribed. Indeed, if the user of the terminal (or the terminal loosely speaking) has subscribed to a service of “Orange TV” (trademark) type for example, this user must be able to receive this service on his terminal, whatever the network to which the terminal is connected.
This switchover or handover from a first network to a second network may give rise to a latency period, the time while the second network is added to the multicasting tree of the multicasting group considered. During this period, the terminal cannot receive the services to which it has subscribed, this not being acceptable.
The document “An efficient mobile multicast mechanism for fast handovers: a study from design and implementation in experimental networks” (D. H. Kwon at al., Computer communications, 2008) proposes a solution making it possible to reduce this latency period when switching from a first network to a second network.
According to this document, the terminal, which was previously connected to a first network by way of an access router PAR, detects a change of network. It then indicates to the access router PAR of the new network (second network) a list of its multicast subscriptions (multicasting groups to which the terminal has subscribed). On receiving this list, the access router NAR of the second network asks to be added to the multicasting trees of the multicasting groups to which the terminal has subscribed, and asks the access router PAR of the first network to make the corresponding multicast streams follow it.
The multicast streams are then transmitted from the access router PAR of the first network to the terminal, by way of the access router NAR of the second network.
Once the process of subscription of the access router NAR of the second network has terminated, that is to say once the access router PAR of the second network has been added to the multicasting trees of the groups to which the terminal has subscribed, the terminal asks the access router PAR of the first network to stop transferring the multicast streams.
A drawback of this technique is that the terminal must be able to communicate at one and the same time with the router of the former network to which it was connected and with the router of the new network.
Indeed, the terminal must take the initiative to ask the router of the new network (second router) to make the multicast streams to which it has subscribed follow it, by indicating to this second router the multicasting group to which it has subscribed.
Moreover, the terminal must ask the router of the former network (first router) to stop making the multicast streams follow it by way of the second router.
Now, the terminal is not always able to communicate with both networks at one and see same time, especially when the link with the first router is lost following a physical movement of the terminal.
Moreover, this solution is not compatible with the new document RFC 5213 describing a new protocol “Proxy Mobile Internet Protocol version 6” (PMIPv6), specified in August 2008 by the IETF (“Internet Engineering Task Force”), the terminal being active in the handover process. Indeed, one of the constraints imposed in this document is that the handover process is entirely transparent to the terminal (one speaks of “seamless mobility”).